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Cryptographic Key Update Management 
Field of the Invention 

5 The present invention relates to a method and apparatus for managing crj^tographic key 
updates and, in particular, but not exclusively, to the consolidation of key updates for use 
by a re-connecting member of a secure dynamic group where all the group members share 
a secret key that is subject to continual change to match current group membership. 

10 Background of the Invention 

Many applications require an efficient and secure mechanism to distribute information to a 
dynamically changing trusted community. Typically, such a mechanism involves forming a 
secure group whose members share a secret cryptographic key. This key is updated to a 
new version when a new member joins the group (so that the new member cannot access 

1 5 previously shared information protected by the key - so-called "backward confidentiality") 
or leaves the group (so that the leaving member cannot access future shared information 
protected by the key - so-called "forward confidentiality"). The responsibility for 
controlling the shared key, and therefore the membership of the group, is carried out by a 
functional entity which is referred to herein as the key manager. A simple implementation 

20 of the key manager involves the latter making a private communication to a new member 
and each existing member (in the case of a newly joining member), or to each remaining 
member (in the case of a member leaving the group) to provide the new version of the 
shared key. However, in order to make this key update operation more scalable, there are 
well-known techniques that combine a multicast transport with a Logical Key Hierarchy 

25 (LKH) , reducing the complexity of this operation to logarithmic with the size of the group 
(see, for example, "Key management for multicast: Issues and architectures" hitemet 
Request for Comment RFC 2627, Intemet Engineering Task Force, June 1999): 

Unfortunately, robust key management in knovm multicast LKH schemes generally 
30 requires that members are always on-line to reliably receive key updates in a timely 
manner. This can limit the applicability of these schemes when the community is large and 
loosely coupled, or the connectivity between members is poor, or just simply when the 
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most common behaviour of a member is to be off-line. In these cases it can be too 
expensive (in terms of processing and communication resources used) to treatmembers as 
being evicted from the group concerned when they go off-line. 

5 Vanous proposals have been made in respect of improving the reUability of group re- 
keying with a focus on key recovery for on-hne members when there are failures of the 
multicast transport. Such proposals assume that only a few key updates are lost, or that 
members will always be able to take an immediate recovery action. An extreme of this 
approach are key distribution schemes that assume a reliable group communication 

10 middleware underneath, e.g. , extended virtual synchrony semantics, in order to update keys 
reliably. 

m the context of secure distribution of copyright protected material, detailed studies have 
been made concerning how to encrypt broadcasted content so that only a dynamically 
1 5 changing ^oup can decrypt it (see broadcast encryption ), and how to trace and exclude 
possible "traitors" ttiat leak information . Typically, these schemes assume a single source 
and do not deal with an arbitrary number of "traitors" colluding. Moreover, in some cases 
they also assume that clients camiot update state dynamically, e.g., a DVD player with 
some pre-configured secrets, and this can make managing the forever-growing revocation 
20 information impractical. 

The paper "Efficient state updates for key management" Bemiy Pinkas, ACM CCS 
WorkshoponSecurityandPrivacyinDigitalRightsManagement,LNCS2001 considers 

how to minimize the amount of information needed to recover a client that is back on-line 
25 after missing some LKH key updates. However, it is assumed that tins information is 
optimised for a particular chent, and downloaded directly froiri the key manager. 

It is an obj ect of the present invention to facilitate key update management for members of 
a group who have missed a number of updates. 
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Siimmarv nf the Invention 

The present invention takes advantage of the observation that when a group member who 
has been offline becomes active again, he is usually just interested in the key currently 




" being used by the group, and not in all the intennediate keys that were in use while he was 
off-line. This means that not all key updates are necessarily needed by a returning member. 
Li general terms, the present invention provides for the consolidation of the key updates 
multicast by a key manager into a compact representation. 

5 

More particularly, .according to one aspect of the present invention, there is provided 
apparatus for consolidating key updates provided in records that each comprise an 
encrypted key corresponding to a node of a key hierarchy and encrypted using a key which 
is a descendant of that node, hierarchy-node information for both the encrypted and 

10 encrypting keys, and key- version information for at least the encrypted key; the apparatus 
comprising a communications interface for receiving said records, and a manager for 
maintaining, on the basis of the received records, a key tree with nodes corresponding to 
nodes in said hierarchy, the manager being arranged to store in association with each tree 
node, for each encrypting key used in respect of the encrypted key associated with the 

1 5 node, the most up-to-date version of the encrypted key and its version information with any 
earlier versions being discarded. 

As the keys stored in the key tree are in encrypted form, the apparatus can be located in any 
part of the commimications network used for key update distribution and, in particular, can 
20 be situated where it can most reliably receive the key updates from the key manager and 
multicast the key tree, or a subset of it, to returning members. More than one apparatus can 
be provided in the network. 

The key tree is client agnostic which enables the tree, or a subset of it, to be multicast to 
25 returning members without the need for customisation. 

Since pff-Hne members will generally keep state associated with previously known keys, it 
is possible to provide a subset of the key tree for sending to group members whilst still 
enabhng the returning members to determine the current group key, at least within a target 
30 failure margin. 
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p.se„. invention . partculaxly suited for providing key update — ^ » 
Anonymous Group Con.en. De.very (AGCD) .ystem where oonten. . encrypted w«> 

(or a .ey encrypted us.n, the latter). G^terally. in .cK systems ^up 
rlerI.can.eHr^ydyna..candn,ostnren;.ersareU.e,yto.eo«.Une.o3^^^^ 
5 ti„>eThe„ranagen.en.ot.cyupdates.husneedstoha„dleof.-.inen.enrberswen.Totta^ 

end. *e .ey tree, or preferably a su.se. of it, is dis.rrbu.ed along «..h the encrypted 

content. 

I- 

According <o another aspect of me present inventton. drere is provided a method of 
.„ lolidalg .ey updates provided in records each conrpris.g an enc^^e ey 
co^cspondntg to a node of a key hierarchy and encrypted usmg a key whrch s 
IZda„.oLnode,Hierarchy-nodeinfornrationforhoth,h.encrypted^ 
Z andkey.version.nfonnationforatleas.the.encryptedkey.,hen.ethodcon,pnsnrga 

:of.n.nLn.ng,ond.ehas.sofsaidrecords.akeytreewi.nodescorrespo^^ 

,5 nl in said hrerarchy. this tree-ma—e step comprising a sub-step of stonng m 
associationwitheach.eenode,foreachenc.yp..ngkeyusedinrespecto*een<^.^^ 

.ey associated with the.node, the most up-to-date verston of the ^crypted key and .ts 
version information with any earlier versions being discarded 
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- " . ■ ■ . , r„„„ he described by way of non-limitmg example. 

Embodiments of the invention will now be descnbeo, oy , 

with reference to the accompanying diagrammatic ^-^t^- " 

Fteurel is a diagram of a key distribution arrangement; 
: ,U 2 IS a diagram illustrating die operation of a known logical key hie^hy 
manager of the Figure 1 arrangement; 

. t^r. 3 is a dia^am illushating the operationof akeylustory trce.KHT. cacheof 

the Figure I arrangement; and 
.F,gure.4 is a dia^am ^ anonymous group conten. delivery system incotporating a 

KHT cache. 
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The key update management arrangement shown in Figure 1 comprises a key manager 1 0 
for managing the membership of a group 1 1 of cUents (also referred to as group 
members) 14 as well as the generation, organisation and distribution of keys to currently 
on-line group members 14. The Figure 1 arrangement also comprises a Key History Tree 
5 (KHT) cache 20 embodying the present invention and operative to provide consolidated 
key update information to returning clients 1 4 who have been offline and may have missed 
key updates jfrom the key manager 1 0. It will be appreciated that although the clients 1 4 are 
depicted in Figure 1 by person icons, a client may be an autonomous device and even 
where a chent is associated with a human user, that user will be acting through an 
1 0 associated device; the term "client" should therefore be interpreted herein according to its 
context to refer to a client device and/or an associated human user. 

In the Figure 1 arrangement to be described below, the key manager 10 manages a Logical 
Key Hierarchy (LKH) 12 of the general form described in the above mentioned EEFT RFC 

1 5 2627; more particularly, a variant of LKH is employed, called LKH+ that uses key hashing 
to generate new keys in respect of newly added members. In order to facihtate an 
understanding of the present invention a brief description will first be given of the 
operation of the key manager 1 0 in relation to the management of the LKH 1 2 as members 
are added and removed from the group 11. It should, however, be understood that 

20 application of the present invention is not limited to the form of key hierarchy to be 
described below or as described in the above-mentioned RFC 2627 and that the invention 
can be applied to any explicit or implicit key hierarchy. 

The LKH 12 is a hierarchy of keys created by the key manager 10 to facilitate re-keying 
25 consequent on membership changes. For simplicity, the LKH 12 is here taken to be a 
binary tree, although the hierarchy can be easily generahzed to an n-ary tree. As shown in 
Figure 2 in respect of an initial version 12o of the LKH, each node 13 corresponds to a 
secret key K_i_j where i=id(n) is the position in the tree of node n (herein the "node 
identifier"), and j is the version number of this key (herein the "version identifier"). The 
30 . version identifier is initially zero and is incremented by one every time the key changes 
(this version nimiber is never reused for a particular position in the tree). In conventional 
manner, the position identifier of a node in the binary tree is given as follows: 



id(n)-l ifnisroot 
id(n)=2Hd(parent(n)) if n is left child 
id(n)=l+2*id(parent(n)) if n is right child 



2 a.= node idenUfier id(„) o, each node .3 ,s no. expHcMy shown agan.s. each 
, 5 node^tcanhereadilyde— by«.o*eva:.eofrin*eco.^ond», 

key identity KJ J appealing inside eaeh node. 

Each^upnte-nher 14 (iniUally, cUents 1 to 3) is associated »..h a respective leaf node^ 
„e 1^. I. will he assntned th^ each t^tia. cMent 1 to 3 riows all «.e keys tn the pa^ 
.0 •^n,i.sassoeiatedleafnodetothetootcrote.a.p,e..he«alcl^^^^ 

,hesekeysmrespectivesea„e^thentica.edsessionswiththekeyntanagerlO).Therot 

riyKlo,is thus ..ownhyallthe initial .onpnten^he^andcanhensedto 
guarantee confidentiality of group commtmications. 

,5 P,g.esl3nd2deptc.aseriesofchangestogroupnre.hershipwithKg«e2sho™g.h^ 
re^tant changes to the LKH keys (the various versions of the liCH are referenced 12« 
12, respecttvely). The sequence of membership changes consrdered .s: 

- Addition of new client 4 

- Removal (voluntarily or forced) of client 3 
20 - Addition ofnew client 5 

- Removal of client 4 

- Removal of client 2 

r t 4r,vnlves for the purposes of achieving backward 
The adding of a new chent mvolves, lor me p f 
.5 conf.denttaUty.ch3ngingthekeysinthepa«,.o.n«teI«lleafnodeas.cta.edw^*e 

„ewclien.totherootnode.For.heLKH.schentedescribedhere,thtschange.seffec^. 

hashtngeachalfectedkeyusingahashrngalgorithntknowntoallntemhers^dthekey 
lagerlO.Thenewkeyve.tonsofthea,fec.edkeysa«thensenthy.ekeymanag.. 
,henleUento,erasecureparty-to-partycounection,a«ermu»alaudtenhcahon^.s^ 

30 necessarytosendthesenewkeyverstonstothe pre-existing memhers hecause drey ^ 
the^selvesg^eratethenewversionofanyofthesekeysthatheonthenresp^vep^^ 
.odrerootsinrplybyhashingtheexisttagversion^e^yinthenpossesstonOheneedof 




hashing a key before using it to decrypt encrypted information of interest is usually 
apparent jfrom a difference between the version number of the key akeady held by the 
chent and the version number of the key used to encrypt the encrypted information, this 
latter version number generally being supplied along with the encrypted information). 

5 

By way of example, when client 4 is added to the group 1 1 , a new leaf node corresponding 
to a new key K__7_0 is appended to the LKH (see LKH 12i in Figure 2) and the chent 4 is 
associated with this node. The versions of the keys encountered between the key K__7_0 
and the root of the hierarchy, including the root key itself, are hashed to produce respective 
1 0 new versions: thus key K_3_0 is hashed to produce key K_3_l and key K_1_0 is hashed to 
produce K_l_l. The keys K_7_0, K_3_l and K_l_l are then sent , over a secure 
connection to the new client 4. 

When a member is removed from the group 11, in order to ensure forward confidentiality 

15 the key manager 10 must change all the non-leaf keys known to that member and 
communicate the new versions of these keys to all the remaining members. This has to be 
done in a way that does not disclose these new versions of the keys to the removed 
member, or any number of cooperating removed members. The key manager 10 proceeds 
bottom up, changing each key along the path from the node associated with the removed 

20 member (which node is itself removed) to the root node of the LKH, Each new key 
version at one level in the hierarchy is encrypted using the or each of its children 
(descendant node keys) to form a corresponding number of key update records 1 8 (see 
Figure 1) which are then multicast by the key manager 10 for use by the group members 
(see arrow 17). Each key update record 18 comprises, in addition to the corresponding 

25 encrypted key, the node identifier and version identifier of both the encrypting and 
encrypted key, these identifiers being in clear. As a result, each remaining niember receives 
the new versions of the changed keys with the or each new key version that lies on the path 
between the member' s leaf node and the hierarchy root being encrypted using a key which 
that member either already has (or can derive by hashing), and/or can obtain by decrypting 

30 one or more of the encrypted new key versions working upwards from a known key. 
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prior.oremovalofthismen,ber.theLKHex,s..u,vers.onl2,.Uponrem 
Lassooiatednode(*eoneco,respon6ingtok.yK.6.0)isremovedand*elceysK_3_l 

^p.edic.ab.e.su.O.Th=keyW=r«ohynowexis«,n«>=v..,onl2.Uus«^^^^^^^^^ 
,.Thenew.evversionsare*«,enc^-i-i„8«.ei.descendants^™,*efo„ow,„g 

encrypted keys: 
10 - E(K_2_0,K_1_2) 

- E(K_3_2,KJ_2) 

18 .a. a. — by «>e .ey _ .0 (as .aca.ed by .e ..c. s«..b. 

arrows in Figure 2). 

,^„,„ow,oa.on.de«aonof*eKHrcache20eo*odyi„g*ep..e„.invenU^^^^ 
,0 !L, provided.ofacm«.re-.eyingforg.oupmember..«a«.apenod ffl.^^ 

itm Lag. 22 of .he cache 20 is ananged to receive, via co»n„meabons mterface 
::^::ilu..byd.e.ey«eH03nd.oco„soHda.e.e...oa.eyh.s^ 

24 adapl .o enabie any .e.u..ng ^up — . de.e™i„e the c.^. 
g„up key (that is, the cunent version otthe LKH root key). 
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^esyste».adeupofthekeyn.a„ager.0,thecache20,thegroupofoh».^^.^^ 
.J connn-cations inftastruc»re. ca. be configured to operate such fta, the key 

:lger :0 continues to muiticas. the records t8 to all online ^onp members wth ^ 
XcheprovidingKHTinfornra^ontoreturningnrenrbersinanysuitabien^annersuch 

rJr:toI-oindi:idualre,ues.sorbyn.ulticast.However.inana.te.nat.eop^ 

ro^lJa.ion.prefe.edforcertainapp.ications.thekeynranagerlOdoesnotn.u,.^^^^^ 
:^riSbuLp.yprov,des.enrtothecache20whiohconsoUdates.heserecords„to 
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the KHT 24 and multicasts KHT information to all online members whether or not they 
have been offline for any period. 



Each group client should, of course, be satisfied that any KHT information it receives is 
5 genuine before using it; this can be achieved in many different ways such as by using an 
authenticated communications channel with the cache 20, by the cache 20 digitally signing 
the KHT information and/or by the key manager 10 digitally signing records 18 
incorporated into the KHT information. 

10 The KHT information output by the KHT cache 20 can comprise the whole KHT 24; 
however, as will be more fully described hereinafter, the output KHT information can 
advantageously be a subset of the KHT, this subset being chosen on the basis of what 
contextual information is likely to be aheady known by group members. Whilst outputting 
only a subset of the KHT reduces the bandwidth and processing resources consumed, it 

15 does mean that occasionally a returning clientl4 will not have enough information to 
recover the group key; in this case the client will need to contact the LKH key manager 1 0 
directly to re-register using a secure channel. 

The KHT 24 is a simple data structure that is held in a store 23 of the cache 20 and is 
20 created and managed by the manager 22 without any knowledge of the structure of the 
group 11; indeed, the cache 20 does not even have to be a member of the group. In the 
present embodiment, the KHT 24 has the same overall structure as the LKH 12 but each 
node of the KHT stores (or more, generally, has associated with it), for each of its 
descendents, the latest (most up-to-date) record containing its encrypted key that uses the 
25 corresponding descendant key for this encryption. However, as the KHT has to be inferred 
fi-om the records 18 provided by the key manager 10 and as information such as the 
position of a newly added member is not included in these records, the KHT may not track 
exactly the original LKH tree. In fact, by using certain conventions on how the LKH tree 
changes, it is still possible to ensure that all the group members can recover the group root 
30 key. Such a convention provides, for example, that when a leaf node is spUt into two nodes 
to extend the tree, the previous leaf node always occupies the leftmost position. Also, only 
leaf nodes are pruned and not internal nodes with a single descendent. 
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Figure 3 shows how the KHT 24 evolves as a result of the addition and removal of clients 
to the LKH 12 depicted in Figure 2 example. Initially, it is assumed that the KHT simply 
comprisesarootnode30thatholdsnoencrypted-key record for eitherofits two potential 

descendants - this is KHT version 24o. 

Upon the client 4 being added, since the LKH+ method is being used, the key manager 1 0 
aly communicates key information to the new client 4 and no record 1 8 is produced. As a 
ait, the cache manager 22 does not change the KHT so that the KHT version 24^ 
10 existing after the addition of client 4 corresponds to the initial KHT version 24o. 



onl 
resul 



When client 3 is removed from the group 11, the key manager lOsends abatch 34 of three 
records 1 8 to the cache 20, these records respectively comprising encrypted keys E(K_7_0, 
K_3_2), E(K_3_2, K_l_2), and B(K_2_0, K_l_2) together with the related node and 
15 ve^rsionMentrfieisfor&eencryptingandencryptedkeys.TteKHTmanager22det^^^ 

there isanewLKHnode3becauseoftheupdaterecordE(K_7_0,K_3_2),allocatesanew 

KHT node 31 for it, and stores the update record in the new node 31 in respect of its 
implied right child (because the node identifier of the encrypting-key node identifier is an 
odd number, namely "7"). The KHT manager 22 also stores in the KHT root node 30 the 
20 updaterecordsE(K_2_0,K_l_2)andE(K_3_2,K_l_2)inrespectoftheleftandrightchild 

respectively of the root node. The KHT is now in its version 242. 

The addition of cUent 5 to the group 11, like the addition of client 4, causes no changes in 
the KHT so that KHT version 243 is the same as KHT version 242. 
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When the client 4 is removed from the group 1 1 , the key manager 10 sends a batch 35 of 
three update records 18 to the cache 20, these records respectively comprising encrypted 
keys E(K_6_1, K_3_4), E(K_3_4, K_l_4), and E(K_2_0, K_l_4) together with the 
related node and version identifiers for the encrypting and encrypted keys. The KHT 
30 manager22processestheupdaterecordE(K_6_l,K_3_4)bystoringitinthenode31 for 

the left child of the latter. The KHT manager 22 processes the update record 
E(K_2_0,K_l_4)byusingittooverwritetheexistingrecordE(K_2_0,K_l_2)storedinthe 




root node 30 for the left child of the latter since the newly received record refers to a newer 
encrypted version of the LKH root key (version 4 as opposed to version 2). Similarly, the 
KHT manager 22 processes the update record E(K_3_4 JK:_1_4) by using it to overwrite the 
existing record E(K_2_0,K_1_4) stored in the root node 30 for the right child of the latter. 
5 Note that it is not necessary to keep any update record concerning an older key version that 
has been superceded by a more up-to-date version since any record that uses the older key 
version for encryption will itself be superceded by a new record triggered by the change to 
the encrypting key. 

k 

10 When the cUent 2 is removed from the group 1 1 , the key manager 10 sends a batch 36 of 
three update records 18 to the cache 20, these records respectively comprising encrypted 
keys E(K_4_0, K_2_l), E(K_2_1, K_l_5), and E(K_3_4, K__l_5) together with the 
related node and version identifiers for the encrypting and encrypted keys. The KHT 
manager 22 detects that there is a new LKH node 2 because of the update record E(K_4_0, 

15 K_2_l), allocates a new KHT node 32 for it, and stores that record in respect of its left 
child. The KHT manager 22 processes the update record E(K_2_1,K_1_5) by using it to 
overwrite the existing record E(K_2__0,K_1__4) stored in the root node 30 for the left child 
of the latter. Finally, the KHT manager 22 processes the update record E(K_3_4,K__1_5) by 
using it to overwrite the existing record E(K_3_4,K_1_4) stored in the root node 30 for the 

20 right child of the latter. 

Algorithm 1 below describes in more detail the rules used by the KHT manager 22 to 
update the KHT (manager 22 is typically implemented as a processor arranged to execute 
code embodying Algorithm 1). 

25 

Algorithm 1 - Processing update E(K_/_j,K_/_>n) in KHT 

Create in KHT empty nodes in path from root to / (if not present) 
Find node N in KHT at position / 
•IF z is even { //left child 
30 Find E(KJ_x,K_/_j;) the left child record of N 

IF ((m >y) AND (j >= jc)) { 

Overwrite E(K_z_jc,K_/_j;) with E(KJ J,K J_m) 
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} //End IF 
else { //right child 

Find E(KJjc,Kj j^) the right child record of N 

IF((m>3;)AND(/>=^)){ 

Overwrite E(K J_;c,KJ^) with E(K_u,KJ_m) 

} //End IF 

}//EndIF ^ , 

Note ma. if « record U inre.pec.of a descendant of a,e node N, me„«.e values, , 

and y are treated as being -1 . 

Lcanbe seen from Algon.hn,ma.a„upda.ereoordison,ys.oredifbo**eversionof 
fl,eencryp.edteyoo„cem=d.s„.orenp-.c-da.e.hana„yrecordalreadys.oreafor*esan.e 

Key and de.eenda„. (encrypting key), and ,he encrypting .ey nsed is no, older (is no. an 
earUer ve^ion) «.an «.= curren, one. All *e o*« cases can be safely i^ored because 
dU.era.eybreaktebasicIiCH™leofnpda.,ngk.ysbonon,upor*eydono,addnew 

infonnation. Of coarse, i. wonld be possible » arrange for a newly received record .o 
overwrite an existing record where fte encrypted key ve^ions were .he san.e (and the 
encryptingkey used for thenewlyreceivedrecordwasno. older than tha.of*eex,st.ng 

record) but this is not needed. 
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I.n,aya,sobenoted.ha.checkrngU,eencryptingkeyversionshouldno.bere,ntad,fth. 

key nranager is operating correCly and .he upda.es are received in order, since u. *ese 
circun.tancesti.eencryptingkeyversionforareceivedr^rdshou,dno.beearher4an 

mat used for a cor^ponding record already stored „ the KHT 24. Thus. i. .s poss,hle .o 
25 in-plemen. me nranager 22 n. such a ntanner that it does not ch^k the encrypting key 
ve^ion^dthisinfomrationcantitereforebeonuttedinthe records supplied to thecache 

20However.inclusionofd.eencryptingkeyvcrsiontotheupdate,ecordsisprefe,redas.. 
providesrobushressandenablesachenttode.ennineU.enun.herofhashesre,u>red.obe 

made .o derive certain keys, as wUl be more fully explained heremafter. 

With regard to fl.e exac. fonn of Are KHT 24 da.a stnrcb.re. it will be apprecia.ed by 
personsski.ledin*etu.mat.nanydifrerentimp.ementationsarepossible.F„rmermo«.,t 




will be appreciated that the tree structure of the KHT will generally not be explicitly 
represented by links, such as pointers, between node data sets (that is, the data stored in 
respect of each node of the KHT). Instead, the node data sets will typically include data 
impUcitly placing the nodes into a tree arrangement; thus, each node data set can simply 
5 comprise the stored records 1 8 for that node as these records contain sufficient data, in the 
form of the LKH node identifiers, to define the structure of the KHT tree. The node data 
sets can, of course, take forms other than that of stored records 1 8 - for example, each node 
data set could take the form of a specific data structure with a node identifier and entries 
for holding, for each potential child, an encrypted version of the corresponding key, and the 

1 0 version identifiers of the encrypted and encrypting key (the node identifier of the encrypted 
key being, of course, the same as the node identifier of the data structure and the node 
identifier of the encrypting key being, for example, implicit in the ordering of entries in the 
data stmcture). In this case, the manager 22 does not directly store any received record as 
such but extracts any required information for storage in the corresponding node data 

15 structure. 

Where explicit links between KHT nodes are stored as part of the overall KHT data 
structure, then these links themselves (for example, parent-child links and sibling links) 
can be used to identify the nodes so that it becomes unnecessary to store exphcit node 
20 identifiers. 

Returning to a consideration of the specific embodiment of the KHT 24 and manager 22 
described above with respect to Figure 3 in which the KHT node data sets take the form of 
stored records 1 8, whenever the cache 22 provides KHT information to group chents 14, it 
25 does so by sending the stored records 18 constituting all (or part) of the current KHT 
version. 

It will be appreciated that the above-described key tree is cUent agnostic which enables .the 
tree, or a subset of it, to be multicast to returning members without the need for chent- 
30 specific customisation. 



Algcrittan 2 describes «,e processing done by a Cien. 14 .„ upda. «.e. local ^te after 
^vingasetofkeyupdaterecords either d.recUy^om*eI^keyma„gerlOorftom 

the KHT cache 22. 

5 Algorithm 2 - Processing a set of E(K L/,K updates by client 

FOR EACH update E(K J J, K J jn) in post-order tree traversal { 
IF (node i is in path from client to Root) { 

Find key for node / in local cache, namely, key KJ_r 
IF (r<m){ 

Find key for node rin local cache, namely, key KJ_n 

Obtain candidate KJJ by hashing K J_n for (/-«) times 

Obtain Kj_m by decrypting E(KJJ,K_/_«t) with candidate K^U 

IF (K_/_w is OK) { 

Add K_/_w to local cache 

15 }//EndIF 
}//End IF 
}//EndIF 
} //End FOR EACH 

20 First me client 14 orders .he received updates so that updates lower in the tree are 
proclssedfirstEachnpdateisthenprocessedintnmwi^thefirstprocessingst^sbemg 

LmteroutanyupdatethatdoesnotUeonthepathhetweendrecUentand^eUCHrootor 
tt.. does no. relate to a newer Uy version thar. that already stored. If an npdate survrve. 
. ttre filtering steps, the client 14 ^es to decrypt drc encrypted key contained in the npdate 
« hyfinding.heappropriate.eyini.slocalcache(thislccybeingei,heroneprev,on.ystored 
oIonettra.hasbeenrevealeddnringearlie.processingofd,eKHThrfom,a..on).H„wever, 
ineertaincasesthedecryptionkey,ha.theolienthaslocallymightbeanolderve.,ontha„ 
. is„eededinwMcl,caseft=cli=.tha3hesthisolderversionasnrany.i»esasnecessary.o 
„b.aintheac.ua,.ey.There,uirednn.nberofhashe3isindicatedbymedifferenccbe^.e^ 
30 theencryp.ing.Reyversion„u„ber,in*ereceived„pdateandtheversionn„n.ber„ofd.e; 

corresponding key in the local cache. 




Where the whole KHT 24 has been provided to the cUent, all the needed decryption keys 
will either be available in the local cache or will be obtainable by hashing. However, if 
only a subset of the KHT has been provided, it is possible that the subset is inadequate to 
ensure that a needed decryption key can be obtained by hashing. This situation is checked 
5 for in order to avoid polluting the local cache by storing an incorrectly decrypted key. This 
checking is effected, for example, by checking for padding errors that typically arise if 
decryption is done with the wrong key. This padding error check, whilst being a quick way 
to pick up a problem associated with decryption of a particular key update, is not infallible 
and should therefore be associated with a more thorough check. This latter check maybe 

10 one conducted for a batch of update records rather than for each update record. For 
example. Algorithm 2 can be run to completion for a batch of updates with each decrypted 
key produced being temporarily tagged; after Algorithm 2 has finished a check is then 
carried out on the basis of a validator of the LKH root key that was included with the KHT 
information provided to the client. This validator is, for example, aHMAC of a known text 

15 created (and possibly signed) by the key manager 10 using the appropriate version of the 
root key; if this validator cannot be reproduced at the clients, the client either rolls back all 
the tagged keys to their previously stored versions in the local cache or re-registers with the 
key manager, effectively clearing the local cache and then inserting the correct key values. 
Of course, this check effected for a batch of updates can be carried out independently of 

20 whether or not a padding error check is effected in respect of each update. 

If the encrypting-key version number is not included in the key update as indicated 
hereinbefore for a non-preferred embodiment, then the client can work on a trial and error 
basis to determine the number of times, if any, that the decryption key needs to be hashed 

25 in order to satisfactorily decrypt the encrypted key contained in the key update. Thus, for 
example, the client can initially try the decryption key without hashing it and then use the _ 
above-mentioned padding error check to see if the result appears successful ~> if an error is 
detected, the decryption key is hashed once and used again to try to decrypt the encrypted 
key. If an error is again detected, the hashed key is hashed again and so on. This process of 

30 hashing and checking is repeated until eitlier a successful result is achieved or a 
predetermined upper bound on the number of hashes to be tried is reached (for example, 
300 hashes). 
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The p«>c«. of updates «.e KHT 24 in .he KHT cache 24 can only » ™^ 
5 Jin,insi.eand«.s..i.e,y.orapM.yn^eU.oo,.ge.oheeffiaen.,y*— 

L cache 20. However. «s win no. he *e case for ail appiicanons and . .n ybe 
r.ed«».ahene.ofdi.«n....e Whole KHT .oac,ien.l4p.*e.^^^ 

poten^ally in=. Ueep as i. ori^ .=ey (U>a. .s. «.e ^ ^^^J^^ 

Lesponding .0 fl>e UCH leaf node wijh which ^ cUen. ,s asaocaled) and denve from 
10 the KHT and ttiat key Recurrent group key. 

Generally *ough. it will be hi^y desirable for .he KHT infonnation passed .o a clien. 
U r* -bseTof *e KHT maintained by ^e KHT nranager 22. In «s con.ex. n rs 
e^l : in^odnce .e no.on of KHT Working Se. (KHT-WS). T.e KHT-WS rs ^e 
15 n,nnmalsubse.of*eKHr*a.wmallowaUclien.s.orecoverd>ecnxren.vers,onoffl.e 

eyTh.ssnbse.isalsoa«ewi*.hesa.eroo.as.eKHT,sincehiUa.acha„^ 
rakey«gsersach^ge.n..paren.key.Eachleatof«s«eecorresp„ndsU,«,elow.. 
ein*elTco„espond.„g.oakey.ha.arelev3n.chen.canno.derive.us.byha^g 



local keys. 



, .mrc\c.enprator25thatisresponsibleforusing 
The KHT cache 20 includes awortang sc. (WS) generator . . , „„ ,f 

,heKHT24toproduce.hcKHT-WSor.aswiUhesee„,anapproxi™a.,o„tothelatter.^ 

.IwSgeneraL25knewthes.ateofeverycHent(tha.is.kne„wha.keyversrons^h 

Client he d locally) it would be possible to produ. aprecise KHT-WS. Tor exarn Ic .n 
,3 Hgure3ifafterren.ovingcUent2«.eKHTn,anager22wereabletoassun,e*a^^^^^ 
lIwaboutK 1 4.*eh*emanager22couldsafelydeletenode3toobtau,theKHT-WS 
.he n,a:a;er 22 knows that chent 5 aheady has K_3_4 in its local cache (stnce 
Otherwise it would not have been able to decrypt K_l_4). 

30 Whils.i.isposs.ble.oprov.e— .sbywhich*eWSgcnera.r«^^^ 

«.k of *e s.a.e of eve^ cUent 14. in .any appUcations ttus would requ^e a large 

overhead. 




Therefore, in the present embodiment the WS generator 25 is arranged to provide an 
approximation of the KHT-WS without tracking client state information. Ideally, this 
approximation would be conservative enough so that it contains the real KHT-WS but 
small enough to be communicated efficiently; however, generally the approximation will 
5 be such as to result in the occasional failure of a chent to recover the current group key. 

The WS generator 25 derives the KHT-WS approximation by: 

determining the approximate size of the working set, WSsize (effected by functional 
entity 26 in Figure 1), 

10 - computing for each node in the KHT the likelihood P,. of being part of the working 
set. (effected by functional entity 27), and 

forming the approximated KHT-WS by using the WS^ize number of nodes of the KHT 
that have the highest P/ (effected by functional entity 28). 

1 5 How accurately WS^^ze can be determined depends on how much feedback the entity 26 
receives directly or indirectly from the cUents 14 about the usefiihiess of the KHT-WS 
approximations being sent out by the KHT cache 20. Preferably, the entity 26 is notified 
every time a KHT-WS approximation is inadequate and causes a client 14 to fail when 
attempting to recover the current group key. This can be achieved, for example, by 

20 arranging for the key manager 10 to notify the KHT cache every time a client needs to re- 
register with the key manager as a result of a failure to the recover the group key (see 
dashed arrow 19 in Figure 1); rather than a notification being sent to the KHT each time a 
chent re-registers, a notification can be sent at periodic intervals indicating the number of 
failures in the preceding interval: The failure rate feedback provided to the entity 26 is used 

25 by the latter to dynamically adjust the value of WSsize to approach a desired maximum 
target failure rate. The magnitude of these adjustments is computed using a variant of the 
Newton optimization method, and is based on the changes in failure rate caused by 
previous variations of the KHT_WS. 

30 In practice, it has been found that the probabiUty of a failure p/au is a decreasing function of 
WS^ize that becomes zero when WS^ize has its maximum value, i.e., no pruning of the KHT 
has taken place. It is possible to obtain the value of WS^ize needed for a particular target 
failure probabihty ptargety by solving the non linear equation: 
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By flying a «a. ...a..ve .eU^od .o solve i, .oh a. U>e Newton me^od 



gives: 



wsL = ws;i 



..ere . indicates the current .terat.on. In t.e above equation, the denon^ator tern, 
conceming^the slope . the previous -iteration, can he estimate for sn.all vanat^ons of 
concermiig f "well-behaved" with smooth 

WS..e on the basis, validated by observation, that p,./ is well beha 

transitions of slope whereby: 
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,5 Moreove,.i„order.o«alce*ees.i»a.ionof*ederiva.ve™.erob.s.,o „o.se mthe 
«,e sequence of values obtained 03. be su.iec.ed.o low passing ffl-enns an^ 
rr;iesJve,ysn.alWaHa.on.ofWS.Uand*erefo..™„..no,s,>r«..pos,«ve 

13 elin-inated. In pr..ce, «s .eOK-d Uas be. fo»d .o be ,u..e robus., »c.n. 
accurately p,.r^er Within a few iterations. ' 

20 . . . 

^ .e^ds .he de.e™.na«o„ of .be .ela.,ve in>p„.ance P, of eaob KHT node, in *e 

p J. en^i^en. .e en«.y 27 does .b.s on .e bas.s of a oo.bn.«on of a.^. 

previous behaviour of .he clients as «ga.ds how often *ey update Uten s.a.e, and a^ 
« estintate of .he nutnbe. of possMe clienU that will need that node; U .s. of course, also 

possible to take into account different factors. 

The age., criterion concerns how long a .ey update has been in the KHT-WS w.^ 
npda.cs Ota. have never been added to the OTT-WS being given the high^t pnonty » 
30 e^surcthatnewupdatesare,uicMypropagated.ForKeyupdates.ha.havebeen^^d^ 
tt>eKHI-WS..hcirageisco:npu.edby.imes™eachupda.e(or*eassoca.ednode, 




with the time when the update is first added to the KHT-WS, and using this time stamp to 
deteraiine the current age of the update (or node); where tnow is the current time, the age of 
an update (or node) is thus (tnow- ti). 

5 As regards how frequently clients update their state, this can be characterized by an 
exponential distribution of rate X, This state update behaviour is combined with the key 
ageing infonnation to give a probability of an arbitraiy chent needing that key as illustrated 
in the example below. ^ 

10 The number of clients tliat need a particular node is related to the distance to the root, at 
least in the case of a node allocation scheme that tries to keep the tree reasonably balanced. 
For a balanced binary tree, the importance of a key can be taken to be half the importance 
of its parent. 

15 Using the above criteria, the relative importance P/ of each KHT node can be computed 
recursively in the following way where P/ is set to 1 for the root key : 

< 

p. = P^ * 0.5 * Prob(LastAccess > ti) If z # 1 

k. 

where the importance of a key update is half the importance of its parent multiplied by the 
20 probability of an arbitrary chent needing that key update. This latter probability is 
determined as the probabihty that the client last accessed the service associated with the 
key manager before the key version was added to the KHT-WS. Thus: 

Prob(LastAccess > /,) = 1 -(l - e" ^*('-- " ) == e" 

25 

Mtuitively, the longer a key version has been in the KHT-WS the less likely it is to be 
needed, and the more frequent that are accesses to the service by cUents the less likely is 
that they are not up to date with keys. 



After*eapp— s.zeWS.,of«>=wo.«ngs«anda,erelative.npor.anoeP^f^^^ 

KHT node have been de.em>taed, me taCional e„tiV 28 fonn. fte KHT-WS 
approxtoaUo„byu3ing*eWS.,numbe.ofnodesottt,eKHT«..have*eh.#.estP.. 

Hu8 approximation is then output to the clients 14. 

' T^eabove-describedKHToacheaOp^videsagoodbalancebetweenthesizeoftheKHI 
infonnationprovid=dtore.un>ingclientsa„dftegroup.l.eyreeove,yfaitae.a.e.Mv^^^^^ 

*e operation of the KHT cache is Went". Thus, the KHT cache neither n,ed.ates 
authenticatedinteractionsbetweenclientsandtheliCHkeymanagemorneeastoaecr^t 

10 key updates front d.e ntanaget (wi* the result 4at if the KHT cache is comprotnrsed, *e 
coLLial..yofthe.oup.eysisnothreacHed).Mor.ver,sincetheKH^^^^^ 

^ppUed by the cache can take the for. of the update records output by the UCH^ 
manager,the KHT cache c^be added without modiiyingtheclientsofanextsttnglM 

irnplen>entation.TlreUa,keyn,a„agerdoesnotneedtobeawa.thatitscon.ent,^ 

,5 caledbytheKHTc.hehecauseitsc„lyr«,u.redinterac,ionwi.htheKHrcache^ 

..forward" messages to be broadcasted (however, as noted above, perfo^ance of KHT 
pmrnngheuristicscanbeimp.ovedwhentheLKHlceynranageralsoprov,desaddmonal 

information to the KHT cache). 

20 Asthekeysstoredir>mekey.reeareinencryptedfon„.theKHTcache20ca„beloca,ed. 

in any pa« of the comntunications network used for key update distributton and m 
partrcular,canbesi«a.ed„hereitcannrostreliablyr.eive«.ekeyupda^fi.mthekey 

Lager ,Oandmumcastthekeytree,orasubsetofit.toretnmingmenrbers. Morethan 
one KHT cache 20 can be provided in the network. 

" TofaciU.atescalab,li^.theKHTcache20canbearranged.oprovideitsou.puttose«nd- 

level KHT caches that are responsible for respective sub-groups of the chent ^up 11, 
eachsub-groupbeing,nadeupofdrechentsUassociatedw„harespec.,vesub.«eeofthe 

UafhierarchyEachsecond-,evelKHTcacheus«theKHTWomtat.onitrece,vesftom 
30 dreKHTcacheiOtofonnaKirrtreebutonlyinrespectofthekeyupdatescorrespond^ 

to the nodes of the IKH sub-tree with which the second-level cache is assocated plus ^e 
relevantkeyupdatesforthepathfronttherootofthissub-treethattermirratesatttterootof 




the LKH tree. Each second-level KHT cache is arranged to provide KHT information 
either directly to the clients of its associated sub-tree or to third-level KHT caches each 
responsible for a subset of these clients, and so on. 

5 This hierarchical arrangement of KHT caches can be extended to as many levels as desired. 
At each level of this hierarchical arrangement, other than the first level, each KHT cache is 
arranged to maintain its KHT tree only in respect of keys corresponding to the nodes of a 
respective predetermined sub-hierarchy of the LKH and keys for the path from the head of 
this sub-hierarchy that terminates at the root of the key hierarchy. 

10 

With regard to the KHT information passed from a KHT cache to a lower-level KHT cache 
in such a hierarchy, this mformation can (as with the KHT cache 20 of Figure 1) either be 
the whole KHT held by the cache providing the information, or a KHT-WS generated by 
the latter. By arranging for the KHT information to be in the same form as the records 
1 5 output by the key manager 1 0, it i s possible to provide a high degree of flexibiU ty in how 
the KHT caches are arranged. 

It may also be noted that the key manager 1 0, rather than pro\ddijrLg key update records to a 
single KHT cache that is at the head of a KHT-ciache hierarchy, can provide the update 
20 records directly to multiple KHT caches that correspond to the second-level KHT caches 
described above. 

The embodiment of the KHT cache 20 described above with respect to Figure 1 gives 
25 robustness for group re-keying with off-line members when it is lindesirable to either re- 
key every time a member becomes off-line or to trigger an expensive recovery action when 
back on-line. This is the case when members go off-line frequently, the group membership 
^is very large, or it is impossible to accurately determine who is on-line at a particular time. 
Example applications include: 
30 • Mobile wireless secure group communication: due to the limited power available in 
mobile devices, they are off-line most of the time; in addition, the network has 
frequent temporary disconnections. 
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. Looselycoupledsecuregroups:inordertoreduceoverhead,akeyisnotsharedbyall 
members all the time - however the group members do need to synchronize keys 
&om time to time. Additionally, connectivity between group members may be 
reduced by physical location or administrative burdens. 

. Anonymous Group Content Delivery (AGCD): content is distributed to a subscriber 
community (e.g.. to implement a "pay-per-view" scheme) in a manner which ensures 

that the distribution source cannot learn what a particular client downloads. A 
practical solution is to encrypt content with a key shared by the current "paying- 
members, and use multicasting or caching of encrypted content for efficient deUvery. 
However, since these members are not "on-line" all the time, key updates are 
preferably embedded with the content so that the majority of valid members can stiU 
recover the current key. 

Figure 4 shows an AGCD system incorporating a KHT cache. An AGCD server 
installation 40 is arranged to delivery encrypted content over the internet 43 to registered 
clients 14. The server installation comprises a DMZ ("De-Militarised Zone") section 42 
and aback end section 41 separated by security firewalls (not shown). The DMZ section 42 
comprises aregistration front end 44, arepository 48 for encrypted content annotated with 
key update information, and a content delivery front-end server 49. The back end section 
41 comprises an LKH key manager 10, aunit for aggregating key updates output by the key 
manager 1 0, a KHT cache 20, a raw content repository 46. and a content delivery back-end 
unit 47 that encrypts content from the repository 46 and combines the encrypted content 
with KHT information from the cache 20 to form amiotated encrypted content 48 that is 
then stored in the repository 48. 

The Figure 4 AGCD system operates as follows: 

. To become a member of the secure group associated with the content service 
provided by the installation 40, a new cUent 14 registers with the registration front 
end 44 and, after authentication and subscription payment, the new client is provided 
with a set of keys that correspond to a path in the LKH tree, as described above. 

. The changes in the LKH tree consequent on the addition of a new client or removal 
of an existing client (for example, for failing to pay a subscription renewal) results in 
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the key manager 10 outputting key update records. For efficiency reasons, key 
updates are aggregated, preferably over a specific period, by unit 45 before being 
passed on to the KHT cache 20. 

• The aggregated key updates are passed to the KHT cache 20 that calculates the 
minimal update information (the above-described KHT-WS approximation) required 
by currently registered clients 14 to enable them recover the new group key (with a 
target failure probability). 

• The content delivery back-end unit 47 uses the current group key to encrypt the 
content that will be provided to subscribers and adds to it the KHT-WS 
approximation fi-om the KHT cache 20. In a preferred variant, in order to reduce the 
overhead of re-encrypting previous content when the group key changes, the group 
keys are used to encrypt keys that are more "permanent", but unique for each content 
unit, and these are the ones actually used for encrypting content. The encrypted 
content, the related KHT information and the encrypted content key are stored in the 
repository 48. 

• The content delivery firont-end server 49 forwards the encrypted content, annotated 
with the related KHT information and the encrypted content key, to whoever requests 
it. This is done without authenticating clients or needing to know keys, so that 
content can be cached or multicast without reducing security or adding overhead in 
the server 49 and without breaching the anonymity of the clients: 

• Chents download the annotated encrypted content from the server 49 and try to 
decrypt it using their current knowledge of the group key, or the keys that they can 
derive from the annotated KHT information. If a chent can successftiUy decrypt the 
received content, it updates its local state with the new keys. 

• If a client cannot recover the group key from the aimotated KHT information, the 
client has to authenticate itself again with the registration front end 44 to obtain the 
•new keys. 

It will be appreciated that many variants are possible to the above described embodiments 
of the invention. For example, whilst in the above-described embodiment of the KHT 
cache 20, the KHT 24 is separately maintained from the KHT-WS, it would be possible. 



... . thP KHT 24 to the KHT-WS each time KHT infonnation 
though not preferred, to prune the KHl 24 to ine jvrx 

was output. 

Wi*regaM«>fl.e.ey update reco.asoutpu.bymeLKH.ey..anase.lO,*ehier.chy- 
, nodeanaWversio„i„fo=>a.ontoo,„ded.neac,,,eco.afo.theenc,^U„ga.a«>c^^^ 

can b. provided in forms o*er ^ as respective expUoi. ide„.,fiers and may b 
pldedinin^«forn,.Forexan>p.e. for *eLKH node— gscbentedesen^^^ 
above,*eLKHhieran:hynodennn,bcrof*eencryp,ed.eycanbederivedftom.hatof 
.beenc^.ing.eybyba,ving*e,a«erandronnd.nsi.down.otbeneares..„.^erv.^ 

0 *us, taciusion of me encrypting key bdera.hy-node identifier n, a key up date record 
effetive>ya,soprovidesbierarchy-nodeinfonnationab«u.*eencrypted.ey.F— re. 

^ventbeversionn„.berofoneof*eenoryptingandencryp.^keys.tbeversionn,nn^ 
0, *e oti>er Uy can be expressed as a delta (change in version number) relative - * 
^ven version number. Witir regard to vers,on mformation about tire encr^ting J 
,5 . ieadyindicated,tMs— ioncanbeo.ittedftom.be.eyupdaterecords ti^^^^ 

is no. prefers. Finally, and agatn as a.eady .nd.ca.ed. .be form .n wlncb versron 
iufoJtionaboutti.eencrypted.eyismc,uded.na.eyupdaterecordmayd.frerftomthe 

form in which this information is held in the KHT tree. 



c 



25 



CLAIMS 

1. Apparatus for consolidating key updates provided in records that each comprise an 
5 encrypted key corresponding to a node of a key hierarchy and encrypted using a key which 
is a descendant of that node, hierarchy-node information for both the encrypted and 
encr>T>ting keys, and key- version information for at least the encrypted key; the apparatus 
comprising a communications interface for receiving said records, and a manager for 
maintaining, on the basis of the received records, a key tree with nodes corresponding to 
10 nodes in said hierarchy, the manager being arranged to store in association with each tree 
node, for each encrypting key used in respect of the encrypted key associated with the 
node, the most up-to-date version of the encrypted key and its version information with any 
earlier versions being discarded. 

15 2. Apparatus according to claim 1, wherein the manager is arranged to store each said 
most up-to-date version of a said encrypted key by storing the record containing the latter 
with any previously-stored record that is thereby superseded being discarded. 

3. Apparatus according to claim 1 , wherein the manager is arranged to store in association 
20 with each tree node, along with the most up-to-date version of the corresponding encrypted 

key stored for each encrypting key used in respect of that encrypted key, version 
information for the encrypting key used to encrypt said most up-to-date version of the 
encrypted key, this version information being included in the record providing said most 
up-to-date version of the encrypted key. 
25 ' 

4. Apparatus according to claim 3, wherein the manager is arranged to replace the version 
of the encrypted key stored in association with a tree node for a particular encrypting key, 
with any subsequently received later version of that key provided the latter has been 
encrypted with a version of the encrypting key that is the same or later than the version 

30 used for encrypting the existing stored encrypted key. 



5 Appaxa^s according .0 data 1, «her comprising a worHng-»e. g<.era» fo 
pjlg *e .ey «ee .o genera, a su.se. ofOre «ee pna^iing, aUeas. wr*m a 
Lurera.e.aUclie„. associated wi*e,e.eyUerarchy.recovermec™n.roo.keyof 



the latter. 



Apparatus according to claim 5. wherein *e worHng se. gene«.or compnses con. 
.eaTfor receiving feedback on *e curren. roo.-.ey recovery failure rate and for 
:l„ing*es.eofsaidsubsenoapproach*e3cnralfar.urera.e.saidrarge.fadure 



rate. 



V. Apparaurs accord^ng to Claim 6, whe«in «.e wor^ng set generator Sn^er «mpn^ 
nrearlfcrdetermimngthe— dofatreeuodebeingre^uiredto^^ler^^^^^^ 

current root key. these means hemg basrf on at least one of the age of fte node, or an 
r^.edkeyLoctateaw..hi,andanestn„a.eof*e„umherofpossihlecU«,.stha.wtl, 

15 need the node. 

S. Apparatus according to claim 1 . wherein *e manager .s arr^ged to "J 
onlylspectofkeyscorrespondingto^enodesofapredetenmnedsuVhreorcyofs.^^^ 

hi Jarchy and keys for the pa* ftom Ore head of this suh-hierarchy that termma.es a. the 

20 root of the hierarchy. 

9:Asys.emcomprismgappara.usaccordingtoclaiml.andakey-hierarchyma..g^ 
^gingsatdkeyhterarchyndependenceon^eadditionand/orremovalo members^ 

rgroupLkey-h.erar.bymanagerbeh,garrangedtoou.putsaidrecordsbo.htoo„ne„dy 
IJ;em«nbersofsaidgroupandtosa,dapparat„sasnotiflca.ionof.hecbangesn^e 

by the key-hierarchy manager to the key hierarchy, sard apparatus bemg arranged to 
,Ldesaldkey.ree.orasubsetofMomembersofsa.dgroupwhosubs.uen.lybecome 

availableasaconsobdatednotificattonofthecbangesmadehythekcy—ym^^^^ 
tothekeyhierarchywherebytoenablethesememberstor^^verthecurreutr^tkeyof^e 

30 keyhietarchyatleastwithiitatargetfeiluremargin. 




10. A system comprising apparatus according to claim 1 , and a key-hierarchy manager for 
managing said key hierarchy in dependence on the addition and/or removal of members to 
a group, the key-hierarchy manager being arranged to output said records to said apparatus, 
said apparatus being arranged to provide said key tree, or a subset of it, to members of said 

5 group as a consolidated notification of the changes made by the key-hierarchy manager to - 
the key hierarchy whereby to enable these members to recover the current root key of the 
key hierarchy at least within a target failure margin. 

1 1 . A system according to claim 1 0, wherein the key-hierarchy manager and said apparatus 
10 form part of an anonymous group content distribution arrangement; the key tree, or a 

subset of it, being sent to group members in association with content encrypted with a key 
that is one of: 

the key-hierarchy root key, and 

a key encrypted using the key-hierarchy root key and provided in encrypted form 
1 5 along with the encrypted content. 

12. A system comprising multiple apparatuses according to claim 1, and a key-hierarchy 
manager for managing said key hierarchy in dependence on the addition and/or removal of 
members to a group and for outputting key update records reflecting changes made to the 

20 key hierarchy; the apparatuses being configured in a multiple-level hierarchical 
arrangement comprising a first-level apparatus arranged to receive the records output by 
the key-hierarchy manager, and one or more lower levels of apparatuses each arranged to 
receive the key tree, or a subset of it, produced by a said apparatus at the next level up, the 
apparatuses at the lowest level of the hierarchical arrangement each being arranged to 

25 provide its key tree, or a subset of it, to a respective sub-group of members of said group; 
the apparatuses at each level of said hierarchical arrangement, other than said first level, 
each being arranged to maintain its said tree only in respect of keys corresponding to the 
nodes of a respective predetermined sub-hierarchy of said key hierarchy and keys for the 
path from the head of this sub-hierarchy that terminates at the root of the key hierarchy. 

30 

13. A method of consolidating key updates provided in records each comprising an 
encrypted key corresponding to a node of a key hierarchy and encrypted using a key which 
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is a descendant of that node, hierarchy-node information for both the encrypted and 
encrypting keys, and key-vfersion- information for at least the encrypted key; the method 
comprising a step of maintaining, on the basis of said records, a key tree with nodes 
corresponding to nodes in said hierarchy, this tree-maintenance step comprising a sub-step 
5 of storing in association with each tree node, for each encrypting key used in respect of the 
encrypted key associated with the node, the most up-to-date version of the encrypted key 
and its version information with any earher versions being discarded. 

14. A method according to claim 13, wherein in said sub-step each said most up-to-date 
10 version of a said encrypted key is stored by storing the record containing the latter with any 

previously-stored record that is thereby superseded being discarded. 

15. A method according to claim 13, wherein in said sub-step the version information of 
the encrypting key used to encrypt said most up-to-date version of the encrypted key is 

1 5 stored with the latter. 

16. A method according to claim 13, wherein in said sub-step the version of the encrypted 
key stored in association with a tree node for a particular encrypting key, is replaced with 
any subsequently received later version of that key provided the latter has been encrypted 

20 with a version of the encrypting key that is the same or later than the version used for 
encrypting the existing stored encrypted key. 

17. A method according to claim 13, further comprising the fiirther step of processing the 
key tree to generate a subset of the tree enabling, at least within a target failure rate, all 

25 cUents associated with the key hierarchy to recover the current root key of the hierarchy. 

18. A method according to claim 17, wherein the further step comprises receiving 
feedback on the current root-key recovery failure rate and controlhng the size of said subset 
to approach the actual failure rate to said target failure rate. 
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19. A method according to claim 18, wherein said further step further comprises 
determining the likelihood of a tree node bemg required to enable recovery the cmrent root 



29 

key, this determination being based on at least one of the age of the node, or of an 
encrypted key associated with it, and an estimate of the number of possible clients that 
will need the node. 

20. A method according to claim 13, wherein said tree is mainatined only in respect of 
keys corresponding to the nodes of a predetermined sub-hierarchy of said key hierarchy and 
keys for the path from the head of this sub-hierarchy that teiTninates at the root of the 
hierarchy, 

21. A method of providing key updates to members of a group, comprising the steps of: 
- • managing a key hierarchy in dependence on the addition and/or removal of members 

to said group and outputting, as notification of the changes made to the key 
hierarchy, records that each comprise an encrypted key corresponding to a node of 

the key hierarchy and encrypted using a key which is a descendant of that node, and 
hierarchy-node and key- version information for both the encrypted and encrypting 
keys; and 

consolidating said records according to the method of claim 13 and providing said 
key tree, or a subset of it, to members of said group whereby to enable these 
members to recover the current root key of the key hierarchy at least within a target 
failure margin. 



Cryptographic Key Update Management 



A method and apparatus is provided for consolidating cryptographic key updates (1 8), the 
consoUdated update information enabUng, for example, a returning member (14) of a 
secure group (1 1) who has been offline, to recover the current group key, atleast in most 
cases. The unconsoUdatedkey updates (18) each comprise an encrypted key, corresponding 
to anode of akey hierarchy (12), thathasbeenencryptedusingakey which is a descendant 
of that node. The key updates (1 8) are used to maintain a key tree (24) with nodes in this 
tree corresponding to nodes in the key hierarchy (12). Each node of the key tree (12) is 
used to store, for each encrypting key used in respect of the encrypted key associated with 
the node, the most up-to-date version of the encrypted key with any earUer versions being 
discarded. The key tree, or a subset of the tree, is then provided (28) to group members 
(14). 



(Figure 1) 
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